Ian Jackson [Fri, 22 Feb 2019 12:24:35 +0000 (12:24 +0000)]
pygrub: Specify -rpath LIBEXEC_LIB when building fsimage.so
If LIBEXEC_LIB is not on the default linker search path, the python
fsimage.so module fails to find libfsimage.so.
Add the relevant directory to the rpath explicitly.
(This situation occurs in the Debian package, where
--with-libexec-libdir is used to put each Xen version's libraries and
utilities in their own directory, to allow them to be coinstalled.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0022-pygrub-Specify-rpath-LIBEXEC_LIB-when-building-fsima.patch
We install libfsimage in a non-standard path for Reasons.
(See debian/rules.)
This patch was originally part of `tools-pygrub-prefix.diff'
(eg commit 51657319be54) and included changes to the Makefile to
change the installation arrangements (we do that part in the rules now
since that is a lot less prone to conflicts when we update) and to
shared library rpath (which is now done in a separate patch).
(Commit message rewritten by Ian Jackson.)
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
squash! pygrub: Set sys.path and rpath
Ian Jackson [Thu, 21 Feb 2019 16:05:40 +0000 (16:05 +0000)]
hotplug-common: Do not adjust LD_LIBRARY_PATH
This is in the upstream script because on non-Debian systems, the
default install locations in /usr/local/lib might not be on the linker
path, and as a result the hotplug scripts would break.
A reason we might need it in Debian is our multiple version
coinstallation scheme. However, the hotplug scripts all call the
utilities via the wrappers, and the binaries are configured to load
from the right place anyway.
This setting is an annoyance because it requires libdir, which is an
arch-specific path but comes from a file we want to put in
xen-utils-common, an arch:all package.
So drop this setting.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Gbp-Pq: Name 0020-hotplug-common-Do-not-adjust-LD_LIBRARY_PATH.patch
Signed-off-by: Hans van Kranenburg <hans@knorrie.org> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0019-sysconfig.xencommons.in-Strip-and-debianize.patch
Also see Debian bug #894013. The current attempt at providing
anti-spoofing rules results in a situation that does not have any
effect. Also note that forwarding bridged traffic to iptables is not
enabled by default, and that for openvswitch users it does not make any
sense.
So, stop cluttering the live iptables ruleset.
This functionality seems to be introduced before 2004 and since then it
has never got some additional love.
It would be nice to have a proper discussion upstream about how Xen
could provide some anti mac/ip spoofing in the dom0. It does not seem to
be a trivial thing to do, since it requires having quite some knowledge
about what the domU is allowed to do or not (e.g. a domU can be a
router...).
Gbp-Pq: Name 0018-vif-common-disable-handle_iptable.patch
(XEN) Xen version 4.11.1 (Debian )
(@)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 19:08:37 UTC 2019
I'd like to see:
(XEN) Xen version 4.11.1 (Debian 4.11.1-1~)
(pkg-xen-devel@lists.alioth.debian.org)
(gcc (Debian 8.2.0-13) 8.2.0) debug=n
Thu Jan 3 22:44:00 CET 2019
The substitution was broken since the great packaging refactoring,
because the directory in which the build is done changed.
Also, use the Maintainer address from debian/control instead of the most
recent changelog entry. If someone wants to use the address to ask a
question, they will end up at the team mailing list, which is better
than an individual person.
Gbp-Pq: Name 0017-Fix-empty-fields-in-first-hypervisor-log-line.patch
Ian Jackson [Fri, 12 Oct 2018 17:17:10 +0000 (17:17 +0000)]
shim: Provide separate install-shim target
When building on a 32-bit userland, the user wants to build 32-bit
tools and a 64-bit hypervisor. This involves setting XEN_TARGET_ARCH
to different values for the tools build and the hypervisor build.
So the user must invoke the tools build and the hypervisor build
separately.
However, although the shim is done by the tools/firmware Makefile, its
bitness needs to be the same as the hypervisor, not the same as the
tools. When run with XEN_TARGET_ARCH=x86_32, it it skipped, which is
wrong.
So the user must invoke the shim build separately. This can be done
with
make -C tools/firmware/xen-dir XEN_TARGET_ARCH=x86_64
However, tools/firmware/xen-dir has no `install' target. The
installation of all `firmware' is done in tools/firmware/Makefile. It
might be possible to fix this, but it is not trivial. For example,
the definitions of INST_DIR and DEBG_DIR would need to be copied, as
would an appropriate $(INSTALL_DIR) call.
For now, provide an `install-shim' target in tools/firmware/Makefile.
This has to be called from `install' of course. We can't make it
a dependency of `install' because it might be run before `all' has
completed. We could make it depend on a `shim' target but such
a target is nearly impossible to write because everything is done by
the inflexible subdir-$@ machinery.
The overally result of this patch is that existing make invocations
work as before. But additionally, the user can say
make -C tools/firmware install-shim XEN_TARGET_ARCH=x86_64
to install the shim. The user must have built it already.
Unlike the build rune, this install-rune is properly conditional
so it is OK to call on ARM.
What a mess.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0015-shim-Provide-separate-install-shim-target.patch
This makes it easier to disable the shim build. (In Debian we need to
build the shim separately because it needs different compiler flags
and a different XEN_COMPILE_ARCH.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Gbp-Pq: Name 0013-tools-firmware-Makfile-Respect-caller-s-CONFIG_PV_SH.patch
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by default (to try to make runtime
addresses less predictable):
https://wiki.debian.org/Hardening/PIEByDefaultTransition
This is of no benefit for the x86 instruction emulator test, which is
a rebuild of the emulator code for testing purposes only. So pass
options to disable this.
These options will be no-ops if they are the same as the compiler
default.
On amd64, the -fno-pic breaks the build in a different way. So do
this only on i386.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com> CC: Jan Beulich <jbeulich@suse.com> CC: Andrew Cooper <andrew.cooper3@citrix.com>
Gbp-Pq: Topic misc
Gbp-Pq: Name toolstestsx86_emulator-pass--no-pie--fno.patch
* Update to new upstream version 4.14.4+74-gd7b22226b5, which also contains
security fixes for the following issues:
- arm: guest_physmap_remove_page not removing the p2m mappings
XSA-393 CVE-2022-23033
- A PV guest could DoS Xen while unmapping a grant
XSA-394 CVE-2022-23034
- Insufficient cleanup of passed-through device IRQs
XSA-395 CVE-2022-23035
- Racy interactions between dirty vram tracking and paging log dirty
hypercalls
XSA-397 CVE-2022-26356
- Multiple speculative security issues
XSA-398 (no CVE yet)
- race in VT-d domain ID cleanup
XSA-399 CVE-2022-26357
- IOMMU: RMRR (VT-d) and unity map (AMD-Vi) handling issues
XSA-400 CVE-2022-26358 CVE-2022-26359 CVE-2022-26360 CVE-2022-26361
* Note that the following XSA are not listed, because...
- XSA-391, XSA-392 and XSA-396 have patches for the Linux kernel.
projects / xen.git / log